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ABSTRACT 

The  Land  Command  and  Control  Information  Exchange  Data  Model  (LC2IEDM)  is  investigated  from  the 
perspective  of  naval  tactical  sonar  data.  The  data  content  of  a  sonar  contact  is  described.  The  contact  data  is 
then  placed  in  the  LC2IEDM  database  structure,  illustrating  both  the  order  and  location  of  data  placement. 
Two  data  units,  related  to  sensor  and  contact  specific  information,  could  not  be  placed  in  the  LC2IEDM. 
General  comments  regarding  the  use  of  codes  when  linking  systems  are  presented. 


1.0  INTRODUCTION 

The  evolution  of  military  systems  has  reached  the  stage  where  developers  are  constructing  systems  that  are 
built  from  other  component  systems  -  commonly  termed  a  system-of-systems.  In  such  developments,  the 
successful  communication  of  data  between  the  systems  is  crucial  to  the  implementation.  The  importance  of 
the  communication  has  resulted  in  considerable  resources  being  dedicated  to  data  exchange  solutions. 

Traditional  solutions  to  data  communications  between  systems  have  involved  individual  translations  between 
the  systems.  In  an  interoperable  environment  consisting  of  n  components,  the  full  communication  between  all 
components  requires  the  development  n(n-l)  data  translations.  Such  a  solution  has  obvious  scalability 
problems  as  the  number  of  components  becomes  large. 

As  a  result,  data  structures  that  are  common  to  all  components  are  now  being  considered  to  provide  a  level  of 
interoperability  among  the  component  systems.  These  data  structures  may  take  the  form  of  exchanged  data 
files  or  a  common  database  (i.e.,  the  LC2IEDM  situation).  By  creating  a  central  or  common  language,  the 
developed  system  requires  2n  translations.  In  this  situation,  each  component  is  required  to  translate  into  and 
out  of  the  common  language  [1]. 

In  the  international  community,  developments  are  underway  to  construct  such  common  language  structures. 
For  example,  the  Land  Command  and  Control  Information  Exchange  Data  Model  (LC2IEDM)  is  a  NATO 
development  intended  to  store  all  information  pertaining  to  an  operation.  The  system,  which  has  been  in  the 
development  cycle  for  about  two  decades,  provides  a  high-level  object  and  resource  view  of  the  battle  space. 

LC2IEDM  is  now  being  used  as  the  focal  point  for  numerous  software  developments  aimed  at  a  fully 
interoperable  coalition.  LC2IEDM  is  also  being  investigated  within  virtual  environments,  under  the  auspices 

Paper  presented  at  the  RTO  1ST  Symposium  on  “Coalition  C4ISR  Architectures  and  Information  Exchange  Capabilities  ”, 
held  in  The  Hague,  The  Netherlands,  27-28  September  2004,  and  published  in  RTO-MP-IST-042. 
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of  The  Technical  Cooperation  Program  (TTCP)  [2],  The  interest  in  LC2IEDM  is  widespread  and  as  a  result, 
LC2IEDM  is  being  promoted  as  a  possible  structure  for  joint  operations.  However,  the  LC2IEDM 
provenance  is  army  operations,  and  its  applicability  to  the  navy  environment  needs  to  be  assessed. 

To  investigate  the  LC2IEDM  system  from  a  naval  perspective,  we  consider  tactical  contact  information  that 
originates  from  sonar  data.  This  report  first  outlines  the  content  of  the  contact  data  and  supporting  metadata. 
In  some  cases,  the  metadata  are  not  strictly  from  a  sonar  contact  source,  but  are  included  in  the  data  to 
illustrate  the  data  characteristics  of  the  LC2IEDM. 


2.0  CONTACT  DATA 

In  a  naval  setting,  a  sonar  contact  may  be  considered  a  real-world  object  that  has  been  identified  using  features 
of  the  acoustic  signal.  Sonar  contact  data  typically  consists  of  spatial-temporal  information  related  to  the  real- 
world  object.  However,  in  this  investigation  we  assume  supplementary  information  on  object  properties  is 
also  available.  For  example,  the  contact’s  country  of  origin  would  be  supplementary  information  resulting 
from  intelligence  rather  than  sonar  contact  data. 

Repeated  observation  of  the  contact  provides  a  series  of  contact  positions,  which  collectively  form  a  track  for 
the  real-world  object.  Such  tracks  are  assigned  unique  identifiers,  or  track  numbers.  The  track  number,  with 
the  course  and  speed  of  the  real-world  object,  form  some  of  the  reported  properties  of  the  contact  (see  Table 
1).  Note  that  the  data  includes  both  kinematic  and  attribute  information  on  the  target  and  sensor  used  in  the 
detection.  For  the  platform  containing  the  sensor,  the  data  includes  the  data  owner,  type  of  sensor  being  used 
and  the  position  of  the  reporting  platform.  As  well,  multiple  track  numbers  are  used  to  represent  a  fusion  of 
many  tracks  to  produce  the  reported  track. 

The  data  being  placed  in  the  LC2IEDM  consists  of  25  data  units  as  described  in  Table  2.  The  data  describes  a 
fictitious  surface  ship  named  HMCS  Grove,  located  at  45°N,  50°W,  operating  a  300  Hz  sonar.  The  sonar  has 
detected  a  submerged  submarine  on  a  bearing  270  ±  6.75°  T,  range  of  12  ±  0.5  km,  at  a  depth  of  100  ±  10  m. 
The  submarine  is  model  1234  from  country  Orange.  These  data  are  placed  in  the  LC2IEDM  system  in  an 
attempt  to  reveal  the  strengths  and  weaknesses  of  the  data  model  [3]. 
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Table  1:  Defining  the  data  characteristics  of  the  contact  and  supplementary  information. 


CHARACTERISTIC 

DEFINITION 

Owner 

Owner  of  the  data.  Note  that  the  owner  is  considered  to  be  the  platform  where  the  sensor  is 
based  that  took  the  measurements  that  identified  the  contact. 

Sensor  Type  and 
Frequency 

Type  of  sonar  sensor  including  the  frequency  of  operation. 

Reporting  Platform 
Position 

Specific  point  in  x,y,z  space  where  the  reporting  platform  is  located. 

Time 

Time  the  contact  position  was  determined. 

Position  Error 

A  measure  of  error  associated  with  the  position  of  the  contact. 

Contact  Course 

The  course  of  the  contact. 

Contact  Speed 

The  speed  of  the  contact. 

Track  Number 

Track  number  of  the  contact. 

Components 

Component  tracks  that  have  been  fused  to  create  the  track. 

Country  of  Origin 

The  contact’s  country  of  origin. 

Domain  of  Operation 

The  spatial  domain  in  which  the  contact  is  capable  of  operations. 

Type  of  Platform 

The  type  of  vessel  the  contact  is  thought  to  be. 

Identifiers 

Any  unique  identifiers  for  the  contact. 

Threat  Level 

The  threat  level  posed  by  the  contact  to  the  Owner. 
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Table  2:  Data  used  to  fill  the  LC2IEDM.  The  important  point  is  determining  whether  or  not  the 
database  can  store  the  described  data.  The  number  in  brackets  following  each  data  content 
description  represents  the  note  number  in  the  following  figures.  An  asterisk  (e.g.,  *) 
indicates  the  content  could  not  be  stored  in  the  LC2IEDM  version  5.3. 


CHARACTERISTIC 

DATA  CONTENT 

Owner 

HMCS  Grove  (2) 

Sensor  Type  and  Frequency 

Sonar  sensor  (8) 

Operating  frequency  300  Hz  (*) 

Reporting  Platform  position 

45  N,  50  W  (14) 

Time 

June  24,  2003  at  11:10:00  UTC  (10) 

Contact  Course 

Due  east  (20) 

Contact  Speed 

5  m/s  (20) 

Other  contact  information 

Contact  is  at  a  bearing  of  270  degrees  from  the  reporting  platform,  with  an  uncertainty 
of  ±  6.75  degrees.  (17) 

Range  is  12  km,  with  uncertainty  of  +  0.5  km.  (17) 

The  depth  of  the  contact  is  100  m  below  the  water  surface,  with  an  uncertainty  of 
+  10  m.  (15) 

Track  Number 

BAD001  (2) 

Components 

This  track  is  a  fusion  of  tracks  1  and  4.  (25,26,27) 

Country  of  Origin 

Thought  to  be  a  unit  from  country  Orange.  (5) 

Domain  of  Operation 

Underwater  (22) 

Type  of  Platform 

Submarine  (5) 

Identifiers 

Known  to  be  a  Model  1234  submarine.  (3) 

Orange  in  colour  with  a  large  yellow  dot.  (3,*  -  the  dot  property  could  not  be  stored) 

Threat  Level 

This  is  a  hostile  submarine.  (11) 
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3.0  DATA  PLACEMENT 

The  LC2IEDM  is  a  highly  normalized  data  model.  This  results  in  considerable  dispersion  of  data  over  many 
tables  within  the  LC2IEDM  database.  In  turn,  this  makes  it  difficult  to  represent  and  document  the  data 
distribution.  This  report  only  briefly  presents  this  dispersion.  A  more  complete  description  can  be  found  in 

[3]- 

The  data  placement  into  the  database  utilizes  extensible  Markup  Language  (XML)  structures  and  the 
Operational  Context  Exchange  Service  (OCXS)  [4],  a  Java  software  suite  developed  by  the  Naval  Undersea 
Warfare  Center  in  the  US.  The  suite  provides  a  consistent  interface  to  LC2IEDM  and  removes  the  details  of 
the  data  placement.  The  data  are  described  in  an  XML  structure  consistent  with  the  physical  naming 
convention  of  the  LC2IEDM.  This  allows  one  to  focus  on  the  content  and  structure  of  the  data  rather  than  the 
software  details  of  interfacing  with  the  LC2IEDM. 

The  placement  of  the  contact  information  into  the  LC2IEDM  database  is  presented  in  Figure  1,  Figure  2  and 
Figure  3.  Each  figure  consists  of  LC2IEDM  tables  and  fields  as  based  on  the  LC2IEDM  documentation  [5]. 
A  rectangular  box  indicates  a  table.  Column  names  and  data  types  are  indicated  within  the  table.  Primary 
keys  are  indicated  as  named  columns  above  the  horizontal  separator  line  for  the  table  and  also  by  the  key 
symbol.  Below  the  separator  line  are  non-key  column  names.  Some  of  the  column  names  are  designated  as 
foreign  keys,  and  are  indicated  by  FK  following  the  column  name. 

Relationships  are  illustrated  using  the  Integration  Definition  for  Information  Modelling  (IDEF1X)  notation 
[6].  This  notation  illustrates  a  relationship  between  tables  as  either  a  solid  or  dashed  line.  The  solid  line 
represents  a  relationship  where  the  foreign  key  is  part  of  the  primary  key  in  the  child  table  (an  identifying 
relationship).  A  dashed  line  represents  a  relationship  where  the  foreign  key  is  not  part  of  the  primary  key  in 
the  child  table  (a  non-identifying  relationship).  A  solid  black  circle  on  the  end  of  a  line  indicates  zero,  one  or 
more  records.  A  diamond  symbol  on  the  end  of  a  line  indicates  zero  or  one  records.  No  symbol  on  the  end  of 
a  line  indicates  one  record.  Finally,  a  red  dot  indicates  a  specialization.  A  specialization  is  a  relationship  that 
requires  a  record  entry  in  a  particular  child  table  based  on  the  content  in  the  parent  table. 

Each  figure  also  contains  a  numbered  series  of  shaded  boxes.  Each  numbered  box  refers  to  a  note  in  the 
figure  caption.  The  numbering  represents  the  order  of  data  placement  within  the  LC2IEDM.  The  order 
requirement  is  a  result  of  the  relationship  specifications  within  the  LC2IEDM. 

Within  each  note  is  a  description  of  content  for  the  particular  table.  Notes  will  reference  table  names  first  by 
using  the  physical  table  name  in  the  figure  (denoted  by  uppercase  characters  above  the  rectangular  box). 
Following  the  first  use  of  the  physical  table  name  will  be  the  logical  table  name  (in  parentheses).  The  logical 
names  will  be  used  from  that  point  onward. 

Figure  1  shows  the  initial  load  of  database  tables.  The  data  inserted  into  these  tables  identifies  the  ownship 
object  and  an  object  associated  with  the  contact.  Properties  of  the  contact  real-world  object  are  also  included 
to  exercise  LC2IEDM  capabilities. 
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RPTD _ 

,  rptdjd:  NUMBER(18)  NOT  NULL 


£4  objjtemjd:  NUMBER(15)  NOT  NULL 

£4  matjd:  NUMBER(15)  NOT  NULL  (FK) 

cat  code:  CHAR(6)  NOT  NULL 
name:  VARCHAR(IOO)  NOT  NULL 
altn  identific  txt:  VARCHAR(255)  NULL 
ownerjd:  NUMBER(II)  NOT  NULL 
update  seqnr:  NUMBER(15)  NOT  NULL 

serial_noJd_txt:  VARCHAR(50)  NULL 
lotjdentificjxt:  VARCHAR(IOO)  NULL 
body_colour_code:  CHAR(6)  NULL 
marking_code:  CHAR(6)  NULL 
marking_colour_code:  CHAR(6)  NULL 
ownerjd:  NUMBER(1 1 )  NOT  NULL 
update_seqnr:  NUMBER(15)  NOT  NULL 

accuracy_code:  CHAR(6)  NULL 
cat_code:  CHAR(6)  NOT  NULL 
cntg_ind_code:  CHAR(6)  NULL 
credibility_code:  CHAR(6)  NULL 
reliability_code:  CHAR(6)  NULL 
rep_date:  CHAR(8)  NOT  NULL 
repjime:  CHAR(6)  NULL 
source_type_code:  CHAR(6)  NULL 
timing_cat_code:  CHAR(6)  NOT  NULL 
refjd:  NUMBER(15)  NULL  (FK) 
ent_cat_code:  CHAR(6)  NOT  NULL 
ownerjd:  NUMBER(II)  NOT  NULL 
update_seqnr:  NUMBER(15)  NOT  NULL 
orgjd:  NUMBER(15)  NOT  NULL  (FK) 


,  orgjd:  NUMBER(15)  NOT  NULL  (FK) 

cat_code:  CHAR(6)  NOT  NULL 
nickname_name:  VARCHAR(IOO)  NULL 
ownerjd:  NUMBER(1 1 )  NOT  NULL 
update_seqnr:  NUMBER(15)  NOT  NULL 


\ 


□ 


- 


*  refjd:  NUMBER(15)  NOT  NULL 


descrjxt:  VARCHAR(255)  NULL 
security_clsfc_code:  CHAR(6)  NULL 
source Jxt:  VARCHAR(255)  NULL 
transJype_code:  CHAR(6)  NULL 
ownerjd:  NUMBER(II)  NOT  NULL 
update_seqnr:  NUMBER(15)  NOT  NULL 


cat_code:  CHAR(6)  NOT  NULL 
rptbljtem Jxt:  VARCHAR(6)  NULL 
stock_noJxt:  VARCHAR(15)  NULL 
supply_class_code:  CHAR(6)  NULL 
ownerjd:  NUMBER(II)  NOT  NULL 
update_seqnr:  NUMBER(15)  NOT  NULL 


RPTD  ABS  TIMING 


,  rptd_absjiming_rptdjd:  NUMBER(18)  NOT  NULL  (FK) 


dur:  NUMBER(13,3)  NULL 
effctv_date:  CHAR(8)  NOT  NULL 
effctvjime:  CHAR(6)  NULL 
effctvJime_precision_code:  CHAR(6)  NULL 
ownerjd:  NUMBER(1 1)  NOT  NULL 
update_seqnr:  NUMBER(15)  NOT  NULL 


\ 


□ 


cat_code:  CHAR(6)  NOT  NULL 
loaded_wt_qty:  NUMBER(12,3)  NULL 
unloaded_wt_qty:  NUMBER(12,3)  NULL 
max_height_dim:  NUMBER(12,3)  NULL 
maxjength_dim:  NUMBER(12,3)  NULL 
max_width_dim:  NUMBER(12,3)  NULL 
ownerjd:  NUMBER(II)  NOT  NULL 
update_seqnr:  NUMBER(15)  NOT  NULL 


OBJJTYPE _ 

^  objjypejd:  NUMBER(15)  NOT  NULL 


cat_code:  CHAR(6)  NOT  NULL 
dummyJnd_code:  CHAR(6)  NOT  NULL 
name:  VARCHAR(IOO)  NOT  NULL 
nationality_code:  CHAR(6)  NOT  NULL 
ownerjd:  NUMBER(1 1 )  NOT  NULL 
update_seqnr:  NUMBER(15)  NOT  NULL 


\ 


. 

MAT_TYPE 

£4  matjypejd:  NUMBER(15)  NOT  NULL  (FK) 

\ 


□ 


□ 


EQPT_TYPE 

) 

£4,  eqptjypejd:  NUMBER(15)  NOT  NULL  (FK) 

\ 


□ 


ELCTRNC_EQPT_TYPE 

^  elctrnc_eqptjypejd:  NUMBER(15)  NOT  NULL  (FK) 


cat_code:  CHAR(6)  NOT  NULL 
subcat_code:  CHAR(6)  NULL 
ownerjd:  NUMBER(1 1)  NOT  NULL 
update_seqnr:  NUMBER(15)  NOT  NULL 


Figure  1:  Shown  here  are  10  tables  used  in  the  initial  filling  of  the  LC2IEDM  database  with  the 

contact  data  from  Table  2.  IDEF1X  notation  [6]  is  used  to  illustrate  the  entity-relationship 
diagram.  The  following  notes  apply  to  the  numeric  identifiers  in  the  figure. 

1:  The  REF  (reference)  table  is  used  to  identify  the  information  source.  Any  reporting 
must  have  an  identified  information  source. 

2:  The  OBJJTEM  (object-item)  table  is  used  to  define  the  relevant  objects.  In  this 
example,  one  object  represents  a  materiel  unit  named  "Red  Force  1"  with  alternate 
identification  being  the  track  number.  A  second  object  item  is  a  materiel  unit  described 
as  "HMCS  Grove".  The  second  object  represents  ownship.  The  MAT  (materiel)  and 
the  ORG  (organisation)  tables  will  reference  these  objects. 

3:  The  MAT  (materiel)  table  is  used  to  describe  the  markings  on  the  contact  object.  The 
markings  are  linked  to  the  object  item  described  by  Note  2. 

4:  The  ORG  (organisation)  table  describes  the  organisations  to  which  the  objects  belong. 
The  organisations  are  also  referenced  in  reporting-data,  as  any  generated  reports  must 
originate  from  a  defined  organisation. 
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5:  The  OBJ_TYPE  (object  type)  table  defines  the  name,  nationality  and  types  of  objects. 
For  this  example,  two  types  need  to  be  defined,  one  for  the  contact  and  one  for  the 
ownship.  Note  that  type  is  different  from  the  actual  object.  In  a  military  context,  the 
type  can  be  thought  of  as  similar  to  the  class  of  ship.  In  the  ownship  case,  the  object 
type  is  defined  by  the  name  "Frigate".  For  the  contact,  the  data  in  this  table  accounts 
for  the  contact  nationality  and  the  class  of  vessel. 

6:  The  MAT_TYPE  (materiel-type)  table  is  used  to  specify  equipment  specific  to  a 
particular  object. 

7:  The  EQPT_TYPE  (equipment-type)  table  is  used  to  indicate  that  for  this  example  the 
material-type  indicated  in  Note  6  is  actually  electronic  equipment. 

8:  The  ELCTRNC_EQPT_TYPE  (electronic-equipment-type)  table  is  used  to  define  the 
specifications  of  the  electronic  equipment.  In  this  example  the  electronic  equipment  is 
described  as  a  sonar  sensor. 

9:  The  record  in  RPTD  (reporting-data)  table  manages  the  actual  contact  report.  The 
timing  information  in  this  table  refers  to  the  database  insertion  time. 

10:  The  RPTD_ABS_TIMING  (reporting-data-absolute-timing)  table  contains  the  contact 
time. 


Figure  2  illustrates  those  tables  related  to  locating  objects  in  space.  The  ownship  is  first  located,  followed  by 
the  range  and  bearing  information  used  to  locate  the  contact.  The  contact’s  position  is  described  using  a  fan- 
area,  or  range  and  bearing  values  with  associated  errors. 
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ORGANIZATION 


OBJ  ITEM  LOC 


/ 


>  locjd:  NUMBER(15)  NOT  NULL  (FK) 

,  objjtemjd:  NUMBER(15)  NOT  NULL  (FK) 

>  objjtemjocjx:  NUMBER(15)  NOT  NULL 

accuracy_qty:  NUMBER(9,3)  NULL 
bearing_angle:  NUMBER(7,4)  NULL 
speed_rate:  NUMBER(8,4)  NULL 
use_cat_code:  CHAR(6)  NULL 
rptdjd:  NUMBER(18)  NOT  NULL  (FK) 
ownerjd:  NUMBER(II)  NOT  NULL 
update_seqnr:  NUMBER(15)  NOT  NULL 


O  B  J  JTE  M_STAT 

'  objjtemjd:  NUMBER(15)  NOT  NULL  (FK) 
,  objJtem_stat_ix:  NUMBER(15)  NOT  NULL 


cat_code:  CHAR(6)  NOT  NULL 
hstly_code:  CHAR(6)  NOT  NULL 
booby JrapJnd_code:  CHAR(6)  NULL 
rptdjd:  NUMBER(18)  NOT  NULL  (FK) 
ownerjd:  NUMBER(1 1)  NOT  NULL 
update_seqnr:  NUMBER(15)  NOT  NULL 


ABS_POINT 

abs_pointJd:  NUMBER(15)  NOT  NULL  (FK) 


,  locjd:  NUMBER(15)  NOT  NULL 


lat_coord:  NUMBER(9,6)  NOT  NULL 
long_coord:  NUMBER(10,6)  NOT  NULL 
angular_precision_code:  CHAR(6)  NULL 
abs_point_ver_distJd:  NUMBER(15)  NULL  (FK) 
ownerjd:  NUMBER(II)  NOT  NULL 
update_seqnr:  NUMBER(15)  NOT  NULL 


pointjd:  NUMBER(15)  NOT  NULL  (FK) 


cat_code:  CHAR(6)  NOT  NULL 
ownerjd:  NUMBER(II)  NOT  NULL 
update_seqnr:  NUMBER(15)  NOT  NULL 


FAN_AREA 

fan_areajd:  NUMBER(15)  NOT  NULL  (FK) 


cat_code:  CHAR(6)  NOT  NULL 
ownerjd:  NUMBER(II)  NOT  NULL 
update_seqnr:  NUMBER(15)  NOT  NULL 


mnm_range_dim:  NUMBER(12,3)  NOT  NULL 
max_range_dim:  NUMBER(12,3)  NULL 
orient_angle:  NUMBER(7,4)  NOT  NULL 
sector_size_angle:  NUMBER(7,4)  NOT  NULL 
ownerjd:  NUMBER(1 1)  NOT  NULL 
update_seqnr:  NUMBER(15)  NOT  NULL 
fan_area_vertex_pointJd:  NUMBER(15)  NOT  NULL  (FK) 


,  surfacejd:  NUMBER(15)  NOT  NULL  (FK) 

cat_code:  CHAR(6)  NOT  NULL 
ownerjd:  NUMBER(II)  NOT  NULL 
update_seqnr:  NUMBER(15)  NOT  NULL 


SURFACE_VOL 

^  surface_volJd:  NUMBER(15)  NOT  NULL  (FK) 

ownerjd:  NUMBER(II)  NOT  NULL 

update_seqnr:  NUMBER(15)  NOT  NULL 

s u rfa c e_vol_dfng_s u rfa c e_id :  NUMBER(15)  NOT  NULL  (FK) 


GEOM_VOL 

%  geom volJd:  NUMBER(15)  NOT  NULL  (FK) 


\ 


cat_code:  CHAR(6)  NOT  NULL 
geom_voljower_ver_distjd:  NUMBER(15)  NULL  (FK) 
geom_vol_upper_ver_distjd:  NUMBER(15)  NULL  (FK) 
ownerjd:  NUMBER(1 1)  NOT  NULL 
update_seqnr:  NUMBER(15)  NOT  NULL 


ver_distjd:  NUMBER(15)  NOT  NULL 


cat_code:  CHAR(6)  NOT  NULL 
dim:  NUMBER(12,3)  NOT  NULL 
precision_code:  CHAR(6)  NULL 
ownerjd:  NUMBER(II)  NOT  NULL 
update_seqnr:  NUMBER(15)  NOT  NULL 


\ 


Figure  2.  Shown  here  are  10  tables  that  continue  the  placement  of  the  contact  data  into  the 

LC2IEDM.  These  tables  are  predominantly  related  to  positioning  information. 

11:  The  OBJ_ITEM_STAT  (object-item-status)  table  is  used  to  describe  the  status  of  a 
particular  object.  In  this  example  the  contact  is  described  as  “hostile”. 

12:  The  LOC  (location)  table  is  used  to  categorize  the  types  of  locations.  In  this  case,  we 
categorize  three  locations:  a  point,  a  surface  and  a  volume.  Note  that  the  location 
table  does  not  spatially  define  a  location,  but  rather  assigns  an  identifier  to  the 
location. 

13:  The  POINT  (point)  table  is  used  to  categorize  the  point.  In  this  example  we  describe 
absolute  points. 

14:  Having  defined  an  absolute  point,  the  ABS_POINT  (absolute-point)  table  is  used  to 
store  the  coordinates  of  the  ownship. 

15:  The  VER_DIST  (vertical-distance)  table  is  used  to  store  the  vertical  extent  of  the 
volume  for  the  contact.  Note  that  LC2IEDM  Version  5.3  does  not  allow  negative 
values  (the  next  iteration  of  the  model,  called  the  Command  and  Control  Information 
Exchange  Data  Model  Version  6.1  does  allow  negative  depths).  Storing  the  vertical 
extent  of  the  contact  area  of  uncertainty  means  the  C2IEDM  can  represent  the  ±  10m 
indicated  as  the  depth  uncertainty  in  Table  2. 

16:  The  SURFACE  (surface)  table  is  used  to  categorize  the  surface.  In  this  example  we 
describe  the  surface  as  a  fan  area. 
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17:  The  FAN_AREA  (fan-area)  table  is  used  to  describe  the  minimum  and  maximum 
range,  and  the  orientation  and  sector  size  of  the  fan. 

18:  The  GEOM_VOL  (geometric-volume)  table  is  used  to  define  a  geometric  volume.  In 
this  case,  the  volume  is  described  by  a  surface  with  a  vertical  extent. 

19:  The  SURFACE_VOL  (surface-volume)  table  defines  a  surface  volume  as  based  on  a 
particular  surface.  In  this  case,  the  surface  is  a  fan  area. 

20:  The  OBJ_ITEM_LOC  (object-item-location)  table  assigns  an  object  item  to  a  particular 
location.  This  table  is  used  to  link  the  ownship  with  the  specific  location  that  was 
categorized  as  a  point,  and  the  contact  that  was  categorized  as  a  volume.  The 
contact’s  course  and  speed  are  also  stored  in  object-item-location. 

Figure  3  shows  those  tables  related  to  the  mobility  of  the  contact  and  the  track  fusion  specification.  Track 
fusion  in  LC2IEDM  is  represented  as  a  context  record  that  identifies  the  two  initial  records  (/.  e. ,  initial  tracks) 
that  have  been  combined  to  form  the  fused  track. 


4.0  DISCUSSION 

Two  obvious  problems  were  encountered  in  the  data  load  into  the  LC2IEDM.  The  first  problem  is  related  to 
the  frequency  of  the  sonar  (Table  2).  This  level  of  equipment  specific  information  is  not  present  in  the 
LC2IEDM.  If  users  required  this  level  of  information,  extensions  to  the  table  structure  would  be  required  (and 
are  possible  in  the  larger  LC2IEDM  system).  The  second  point  is  that  the  ‘dot’  property  of  the  colour 
identifier  (Table  2)  was  not  loaded  into  LC2IEDM.  This  property  is  described  in  LC2IEDM  using  a  list  of 
allowed  codes,  the  most  applicable  code  being  ‘symbol’. 

As  a  more  general  comment,  LC2IEDM  is  rich  with  many  codes.  Codes,  which  are  simply  abbreviated  or 
hieroglyphic  representations  of  larger  definitions,  are  used  throughout  many  of  the  tables  within  LC2IEDM. 
The  general  problem  of  code  mapping  will  be  encountered  when  attempting  to  link  systems  to  the  LC2IEDM. 
When  systems  are  joined  in  an  interoperable  way,  an  important  and  implicit  requirement  is  that  the  central  set 
of  codes  accommodates  the  requirements  of  every  component  system.  Code  mappings  are  relationships 
between  code  sets  from  two  or  more  systems.  Such  mappings  are  complex  and  tedious,  requiring  subject 
expertise  in  both  domains  [7]. 

The  combination  of  codes  within  the  LC2IEDM  presents  other  difficulties.  In  defining  the  content  of  the  data 
structure,  codes  are  often  used  to  provide  discrete  information  units  for  an  object.  When  these  data  units  are 
combined,  they  can  often  lead  to  impossible  combinations  of  attributes  associated  with  the  object.  Possible 
solutions  to  such  problems  include  database  intersection  tables  or  business  rules  [2], 

The  code  combinations  present  in  the  reporting-data  table  illustrate  this  problem.  Table  3  shows  four  fields 
and  field  descriptions  present  in  the  table  [2].  The  attribute  codes  indicate  that  the  reported  data  is  based  on 
fact,  from  a  completely  reliable  source  that  does  not  produce  erroneous  information.  Yet,  the  accuracy  code 
indicates  that  the  reported  data  is  probably  erroneous. 

A  final  LC2IEDM  observation  is  related  to  the  sensor  information  and  data.  The  present  investigation 
assumed  the  contact  data  was  supplied  from  some  other  tactical  system.  We  noted  that  the  detailed  sensor 
information  was  not  stored  in  LC2IEDM  because  the  model  does  not  include  data  close  to  the  sensor. 
However,  in  some  cases  it  may  be  useful  to  share  the  data  feeding  the  tactical  system.  Such  data,  when  shared 
with  other  data  feeds  from  remote  platforms,  may  serve  to  discover  contacts  not  obvious  in  either  individual 
system. 


RTO-MP-IST-042 


10-9 


UNCLASSIFIED/UNLIMITED 


UNCLASSIFIED/UNLIMITED 


Assessing  the  Land  Command  and  Control  Information 
Exchange  Data  Model  using  Naval  Tactical  Contact  Data 


ORGANIZATION 


,  capabjd:  NUMBER(15)  NOT  NULL 


cat_code:  CHAR(6)  NOT  NULL 
subcat_code:  CHAR(6)  NULL 
day_night_code:  CHAR(6)  NULL 
uom_code:  CHAR(6)  NOT  NULL 
ownerjd:  NUMBER(II)  NOT  NULL 
update_seqnr:  NUMBER(15)  NOT  NULL 


RPTD _ 

,  rptdjd:  NUMBER(18)  NOT  NULL 


OBJ_ITEM_CAPAB 

objjtemjd:  NUMBER(15)  NOT  NULL  (FK) 

,  capabjd:  NUMBER(15)  NOT  NULL  (FK) 

,  objJtem_capabJx:  NUMBER(15)  NOT  NULL 


MOB  CAPAB 


accuracy_code:  CHAR(6)  NULL 
cat_code:  CHAR(6)  NOT  NULL 
cntgJnd_code:  CHAR(6)  NULL 
credibility_code:  CHAR(6)  NULL 
reliability _code:  CHAR(6)  NULL 
rep_date:  CHAR(8)  NOT  NULL 
rep  Jim  e:  CHAR(6)  NULL 
sourceJype_code:  CHAR(6)  NULL 
timing_cat_code:  CHAR(6)  NOT  NULL 
refjd:  NUMBER(15)  NULL  (FK) 
ent_cat_code:  CHAR(6)  NOT  NULL 
ownerjd:  NUMBER(II)  NOT  NULL 
update_seqnr:  NUMBER(15)  NOT  NULL 
orgjd:  NUMBER(15)  NOT  NULL  (FK) 


msn_primacy_code:  CHAR(6)  NULL 
qty:  NUMBER(12,3)  NULL 
rptdjd:  NUMBER(18)  NOT  NULL  (FK) 
ownerjd:  NUMBER(1 1)  NOT  NULL 
update_seqnr:  NUMBER(15)  NOT  NULL 


>  mob_capabJd:  NUMBER(15)  NOT  NULL  (FK) 

cat_code:  CHAR(6)  NOT  NULL 
terrainJype_code:  CHAR(6)  NULL 
ownerjd:  NUMBER(II)  NOT  NULL 
update_seqnr:  NUMBER(15)  NOT  NULL 


23 

/ 

27 

CONTXT  ELMT 


*  contxtjd:  NUMBER(15)  NOT  NULL  (FK) 

,  contxt_elmtJx:  NUMBER(15)  NOT  NULL 


\ 


rptdjd:  NUMBER(18)  NOT  NULL  (FK) 
ownerjd:  NUMBER(II)  NOT  NULL 
update_seqnr:  NUMBER(15)  NOT  NULL 


26 

CONTXT  RPTD  ASSOC 


Q,  contxt  id:  NUMBER(15)  NOT  NULL  (FK) 

£)*  rptd  id:  NUMBER(18)  NOT  NULL  (FK) 

£4  contxt_rptd_assocJx:  NUMBER(15)  NOT  NULL 

CONTXT 

contxtjd:  NUMBER(15)  NOT  NULL 

cat_code:  CHAR(6)  NOT  NULL 

name:  VARCHAR(80)  NULL 

ownerjd:  NUMBER(1 1)  NOT  NULL 

• - 

owner  id:  NUMBER(II)  NOT  NULL 

update_seqnr:  NUMBER(15)  NOT  NULL 

- 

update  seqnr:  NUMBER(15)  NOT  NULL 

Figure  3.  The  final  illustration  shows  six  new  tables  (RPTD  is  repeated  from  Figure  1).  These  tables 
describe  the  capability  of  the  contact  and  identify  that  the  contact  is  based  on  fused 
information. 

21 :  The  capabilities  of  the  contact  are  described.  The  CAPAB  (capability)  table 

categorizes  functions  that  may  be  performed.  In  this  example  we  use  the  table  to 
categorize  the  mobility  of  the  contact. 

22:  The  MOB_CAPAB  (mobility-capability)  table  identifies  the  mobility  of  the  contact.  In 
this  example  we  describe  the  contact  as  subsea. 

23:  The  OBJ_ITEM_CAPAB  (object-item-capability)  table  provides  links  between  the 
object  item  (e.g.,  the  submarine),  the  capability  of  the  object  (e.g.,  its  mobility  is 
subsea),  and  the  report  pertaining  to  the  object. 

24:  To  represent  a  fusion  of  contact  information,  the  CONTXT  (context)  table  must  first 
define  a  context.  The  context  is  given  a  description  and  a  unique  identifier. 

25:  The  context  will  be  linked  to  reports  in  the  reporting-data  table.  For  this  example,  the 
table  must  be  filled  with  reports  with  IDs  1  and  4. 

26:  The  CONTXT_ELMT  (context-element)  table  then  describes  the  context  in  terms  of  the 
elements  that  make  up  the  context.  In  this  case,  reports  corresponding  to  IDs  1  and  4 
are  linked  to  individual  elements  in  the  context. 

27:  The  CONTXT_RPTD_ASSOC  (context-reporting-data-association)  table  then  links  the 
report  to  the  context.  This  then  describes  one  report  as  a  fusion  of  two  other  reports. 
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Table  3:  Codes  are  used  extensively  within  the  reporting-data  table.  Some  code  values  contradict 
other  code  values  that  can  be  used  in  the  same  record.  For  example,  the  codes  shown  below 
are  valid  in  a  single  reporting-data  record,  but  are  contradictory.  Reproduced  from  [2]. 


ATTRIBUTE 

CODE 

CODE  DESCRIPTION 

accuracy-code 

5 

Reported  data  shall  be  considered  as  probably  erroneous. 

category-code 

REP 

A  REPORTING-DATA  that  points  to  data  based  on  fact  or 
observation. 

credibility-code 

RPTFCT 

Data  is  reported  by  different  sources  whose  integrity  is  not  in 
question. 

reliability-code 

A 

The  source  of  the  reported  data  can  be  considered  as  completely 
reliable  (i.e.,  erroneous  information  cannot  be  produced). 

5.0  CONCLUSIONS 

The  practical  experimentation  of  placing  naval  sonar  contact  data  into  the  LC2IEDM  structure  helps 
demonstrate  more  generally  applicable  issues  related  to  coalition  information  interoperability.  The 
normalized  structure  of  the  LC2IEDM  results  in  considerable  dispersion  of  information  throughout  the 
database.  Such  dispersion  may  have  implications  for  the  subsequent  retrieval  and  reconstruction  along  with 
issues  of  responsiveness.  The  issue  of  dispersion  is  illustrated  by  the  placement  of  the  contact  information 
into  33  records  in  26  tables  within  the  LC2IEDM.  However,  the  dispersion  is  a  result  of  the  normalization 
process.  Normalization  with  constraints  provides  the  data  integrity  for  the  system. 

Investigations  into  near-sensor  data  sharing  are  ongoing  at  DRDC  Atlantic  in  the  Networked  Underwater 
Warfare  Technology  Demonstration  Project  [8].  This  Project  will  define  the  data  sharing  requirements  and 
implement  a  sharing  solution  for  a  multi-static  sonar  operation. 

The  practical  experience  of  placing  naval  contact  data  into  the  LC2IEDM  provides  an  opportunity  to  assess 
the  LC2IEDM  from  a  naval  perspective.  More  generally,  the  experience  provides  a  valuable  critique  of  the 
data  model  and  identifies  potential  integration  issues  with  other  systems. 
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Contact  and  Supplementary 
Information 


Owner 

Sensor  type  and  Freq. 
Reporting  Platform  Pos. 
Time 

Contact  course,  speed, 
bearing  and  range 


Track  Number 
Components 
Country  of  Origin 
Domain  of  Operation 
Type  of  Platform 
Identifiers 
Threat  Level 
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Contact  and  Supplementary 
Information 

Owner  -  HMCS  Grove 
Sensor  -  Sonar,  300  Hz 
Position  -  45  N,  50  W 
Time  -  June  24,  2003  at  11:10:00 
Contact  Course  -  90  ° 

Contact  Speed  -  5  m/s 
Contact  Bearing  -  270  °  ±  6.75  ° 
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Contact  and  Supplementary 
Information 

Contact  Range  -  12  ±  0.5  km 
Contact  Depth  -  1 00  ±  1 0  m 
Components  -  1,4 
Domain  of  Operation  -  Underwater 
Type  of  Platform  -  Submarine 
Identifiers  -  Large  Yellow  Dot 
Threat  -  Hostile 
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Issues 


Codes 

-Hieroglyphic  representations 
-Definitions,  exact  form,  matching 
-Mappings  between  code  sets 
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ruy  Issues 

•  Code  Combinations 


accuracy-code  5 
category-code  REP 

credibility-code  RPTFCT 

reliability-code  A 


data  probably  erroneous 
data  based  on  fact 
or  observation 
multi-sources,  integrity 
not  in  question 
source  completely 
reliable 
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Issues 


•  No  location  (Sonar  Freq.  and  “dot”) 
-DB  Extensions 
-Required  for  details 
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1  {ij  Future  Activities 


•  Using  CA  Implementation, 
establish  DB-to-DB  transfer 
(intra-lab,  inter-lab,  international?) 


Investigate  Naval  Extensions 
Link  to  Tactical  DB  Development 
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n£f  Summary  and  Conclusion 


Possible  content  for  Naval  contact 
Fictitious  data  placed  in  LC2 
Issues 

-  codes 

-  DB  Extensions  for  Tactical  Detail 

Thank  Y  ou. 
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